The Glasgow Virtual Machine Toolkit, GVMT, is a toolkit for constructing high-performance virtual machines. 

The GVMT can be divided into three parts: \begin{itemize}
\item Tools for the creation of interpreters, compilers and other virtual machine components.
\item Library code. Primarily for Garbage Collection.
\item An interface between the user-defined parts of the virtual machine and the toolkit library.
\end{itemize}

All the components operate on a common abstract machine model. It is not necessary to understand this model to use the GVMT, but a knowledge of the abstract machine is useful to get the best out of the GVMT. The abstract machine, which is described in detail in Chapter \ref{chap:abstract}, is a stack-based machine supporting concurrency and garbage-collection. It has an extensible instruction set. The instruction set is abstract in that it cannot be directed executed, but is used to defined the semantics of bytecodes and other code. 

The tools provided by the GVMT can be split into front-end tools which compile source code to the abstract machine model, and back-end tools which convert from the abstract machine code to real machine code.


\section{Example virtual machine}

In order to help understand the GVMT, a simple Scheme implementation is included as an example, it can be found in the \verb|/example| directory. 
This example illustrates all the important aspects of the GVMT, while not being overly complex.

All scheme VMs are implemented by what is known as read-eval-print loop. Its reads the input, evaluates the input and then prints the result, repeating until the interpreter exits. 
The `read' part consists of reading text from a file or terminal and parsing that text to form a syntax tree.

The file \verb|/example/parser.c| contains the parser, it is a standard C(89) source file which can be compiled with the GVMT C compiler, \gvmtc (see Section \ref{sect:gvmtc})

In some scheme implementations the `eval' part is implemented by directly evaluating the syntax tree. This is not the case for the GVMT version, as all GVMT-based VM use bytecode interpreters. The GVMT scheme implementation first compiles the syntax tree to bytecode, then evaluates the resulting bytecode.
The syntax-tree to bytecode compiler code can be found in \verb|/example/compiler.c|.


The bytecode interpreter is defined in \verb|/example/interpreter.vmc|

Although converting to bytecode is extra work it brings two benefits. The first is that the resulting bytecode can be optimised more easily than optimising the syntax tree directly. The second is that the GVMT can produce a bytecode to machine-code compiler automatically.

The Scheme optimiser is a series of passes, which use special interpreters created using \gvmtxc\ (see Section \ref{sect:gvmtxc}).
These passes are defined in the files of the form \verb|/example/XXX.vmc| (except \verb|/example/interpreter.vmc|).

The bytecode to machine-code, or JIT,\footnote{JIT is short for Just-In-Time and is the standard term for runtime compilers} compiler is generated by the \gvmtcc\ tool from the output of \gvmtic.

\section{The Tools}

The GVMT provides a number of tools, which are described in more detail in Chapter \ref{chap:tools}. These can be loosely grouped into front-end tools, and back-end tools. Front-end tools are responsible for compiling source code to the GVMT abstract machine code. Back-ends convert this abstract machine code into an executable virtual machine. 

\subsection{The front-end compilers, \gvmtc\ and \gvmtic}
\gvmtc{} is a C compiler and compiles C files to GSC files.
\gvmtic{} Takes an interpreter specification file and converts into a GSC file.
The interpreter specification is in the form of a list of bytecodes; each of which consists of a name, a stack effect comment and a C code (or GSC) body.

Both tools use a modified version of lcc (lcc-gvmt) to do the compilation. See section \ref{sect:lcc} for more details.

\begin{figure}[htb]
 \centering
 \caption{Building a Virtual Machine using GVMT\label{fig:build}}
 \includegraphics[scale=0.4, bb=36 36 900 700]{build.eps}
\end{figure}

\subsection{The code-generators, gvmtas and gvmtcc}
The code-generators take GSC as input and create object files or executables.

\gvmtas{} compiles the GSC into the GVMT object format, GSO. It works by converting GSC back into C in such a way as to respect the semantics of the GVMT execution model, on a section-by-section basis. \gvmtas{} is also responsible for wrapping the bytecodes in an interpreter loop. 

\gvmtcc{} takes a GSC file containing a bytecode section and produces a bytecode to machine-code. Currently \gvmtcc\ generates llvm-IR\footnote{See llvm.org for more details} and uses LLVM to generate machine-code at runtime (as a JIT compiler).

\subsection{Other tools}

\gvmtxc\ takes a GSC file containing a bytecode section representing the main interpreter, plus a secondary file describing a secondary interpreter. It produces an interpreter (as a GSC file) which uses the bytecodes defined for the main interpreter, but with the semantics defined in the secondary file. \gvmtxc{} can be used for creating bytecode verifiers and disassemblers, as well as optimisers and other abstract interpreters.

The bytecode-transformation engines produced by \gvmtxc{} and the compilers produced by \gvmtcc{} can be used independently or combined to form a specialised optimising compiler.

\glink\ links together all the GSO files produced by \gvmtas\ into a single object ready to be linked by the system linker. See Figure \ref{fig:build}.

\section{GVMT input files}
GVMT takes a number of input files:
\begin{itemize}
\item Interpreter description file(s).
\item Function definition file(s).
\end{itemize}


